home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 14769 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.0 KB
  1. Path: news.mcs.net!usenet
  2. From: Michael Spertus <mps@geodesic.com>
  3. Newsgroups: comp.lang.c++,comp.os.ms-windows.programmer.win32
  4. Subject: Re: VC++ 4.0 memory allocation slower than in 2.x!!!
  5. Date: Mon, 01 Apr 1996 16:00:33 -0800
  6. Organization: Geosdesic Systems
  7. Message-ID: <31606E21.51EB@geodesic.com>
  8. References: <alanDozpsy.Kn6@netcom.com> <315C4DA0.30C@Bentley.com> <316049E7.739D@sdt.com>
  9. NNTP-Posting-Host: jlh.pr.mcs.net
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset=us-ascii
  12. Content-Transfer-Encoding: 7bit
  13. X-Mailer: Mozilla 2.0 (Win16; I)
  14.  
  15. > - This sort of thing can't help but bias benchmarks, as evidenced
  16. >   by last months' Byte Magazine on the subject.  They discovered a
  17. >   similar performance sensitivity to malloc: sometimes (at least, with
  18. >   MS 4.x) it returns byte-aligned allocations, rather than word
  19. >   aligned.  This causes roughly a 50% (20%?) performance penalty on the
  20. >   Pentium for misaligned 32-bit or greater reads, as the hardware has
  21. >   to do some monkey business for things like floats, doubles, ints...
  22. > This is not quite accurate. Windows NT memory allocation always returns
  23. 32-bit aligned data. However, doubles are 64 bit aligned and the Pentium
  24. has a 64 bit data bus, so applications using doubles may be randomly up 
  25. to 300%(!) slower as the BYTEmarks were. Non-aligned loads drop the Pentium
  26. into microcode with huge performance penalties.
  27.  
  28. ** Warning: The following is an interesting anecdote about how this was
  29. ** discovered but also plugs our own product a bit.
  30. This limitation was unearthed in a serendipitous way.
  31. When we visited BYTE labs demonstrating Great Circle (a C++ garbage
  32. collector), they had me drop it into the BYTEmark even though no dynamic
  33. memory allocation was going on during the benchmark loop. We were
  34. flabbergasted to discover that we fixed the problem, even though no
  35. garbage collection took place. This was one step in discovering
  36. that the problem was alignment (because our allocator always properly
  37. aligns data) and also made us aware of a potentially important unexpected
  38. benefit to our product.
  39.